Introducing UsageDetails and Aggregated Cost by Managment Group Scope. Also updated some existing examples to include missing billingperiod in billingPeriodId Property.#3588
Introducing UsageDetails and Aggregated Cost by Managment Group Scope. Also updated some existing examples to include missing billingperiod in billingPeriodId Property.#3588marstr merged 13 commits intoAzure:masterfrom parisa-naeimi:master
Conversation
… Account) Marketplace, Usage Details, and Enrollment Level Balances.
…laced priceHidden boolean type with enum for more clarity
…er-location to some parameters missing that part.
# Conflicts: # specification/consumption/resource-manager/Microsoft.Consumption/stable/2018-03-31/consumption.json # specification/consumption/resource-manager/Microsoft.Consumption/stable/2018-03-31/examples/CostTags.json # specification/consumption/resource-manager/Microsoft.Consumption/stable/2018-03-31/examples/CreateOrUpdateCostTags.json
…. Also updated some existing examples to include missing "billingperiod" in "billingPeriodId" Property.
Automation for azure-sdk-for-rubyNothing to generate for azure-sdk-for-ruby |
Automation for azure-sdk-for-nodeThe initial PR has been merged into your service PR: |
Automation for azure-sdk-for-pythonThe initial PR has been merged into your service PR: |
Automation for azure-sdk-for-javaNothing to generate for azure-sdk-for-java |
|
Can one of the admins verify this patch? |
|
@marstr Hello Martin, Please take a look at this PR and let me know if I need to do something here. Also this PR needs ARMReview. Thank you |
marstr
left a comment
There was a problem hiding this comment.
I have a few comments that should keep your operation groups consistent through-out this swagger.
In general the pattern here does feel kind of backwards here, shouldn't there be an operation group per scope that can have consumption data viewed? Then have UsageDetails and AggregatedCost operations from there? It's not actionable ATM, because it would cause breaking changes without just cause. However, it may be food for thought in future API Versions.
| "tags": [ | ||
| "UsageDetails" | ||
| ], | ||
| "operationId": "UsageDetailsByManagementGroup_List", |
There was a problem hiding this comment.
Please update this to UsageDetails_ListByManagementGroup to reduce the number of separate clients generated by AutoRest.
There was a problem hiding this comment.
Sure, will apply your comment
| "tags": [ | ||
| "AggregatedCost" | ||
| ], | ||
| "operationId": "AggregatedcostByManagementGroup", |
There was a problem hiding this comment.
Please add an Operation Group here. I'd have this operationID be: AggregatedCost_ByManagementGroup
There was a problem hiding this comment.
Sure, will apply it
| "tags": [ | ||
| "UsageDetails" | ||
| ], | ||
| "operationId": "UsageDetails_ListByForBillingPeriodByManagementGroup", |
There was a problem hiding this comment.
ListByForBillingPeriodByManagementGroup seems like a typo to me. Was it supposed to be ListByBillingPeriodByManagementGroup?
There was a problem hiding this comment.
Yeah, It is a typo Good Catch 👍
marstr
left a comment
There was a problem hiding this comment.
Please fix the individual comments noted above.
|
@marstr I addressed all of your comments. Thanks again. |
marstr
left a comment
There was a problem hiding this comment.
Look like the linter has a few good suggestions that should be fixed up. Both the missing x-ms-parameter-location on the global parameter and making sure that Get is added to those OperationIDs we were looking at before. Sorry, I should have caught the missing Get or List earlier!
|
@marstr No worries, I will fix those ones as well. Is it the reason it is failing? cause these ones seem to me as a warning |
Adding new warnings or errors causes the job to fail, but we only block on it if the new warnings or errors are needless. This time we should fix them up, even though they're just warnings :) |
|
Can you give me an example for using location parameter? what do you expect to see there? |
…ethod name of AggregatedCost
|
Yeah, sorry it looks like the documentation the linter links to is missing this rule for some reason. :/ I'll look into that. Anyway, here's an example of the SQL team using it: It needs to be applied on any document-scoped parameter definition so that AutoRest knows whether or not to ask for them as part of a client constructor or in the methods that are generated. You can read more about it here: https://github.com/Azure/autorest/tree/master/docs/extensions#x-ms-parameter-location |
|
@marstr Thank you, I fixed those and sent another iteration |
Automation for azure-sdk-for-goThe initial PR has been merged into your service PR: |
marstr
left a comment
There was a problem hiding this comment.
LGTM, now we'll just need to wait for the ARM team.
|
@marstr Thank you very much 👍 |
|
Looks good |
|
Ready for me to merge, @parisa-naeimi? |
|
Sure, sounds good to me. Thank you @marstr |
This checklist is used to make sure that common issues in a pull request are addressed. This will expedite the process of getting your pull request merged and avoid extra work on your part to fix issues discovered during the review process.
PR information
api-versionin the path should match theapi-versionin the spec).Quality of Swagger